【レポート】非インフラエンジニアでもできる!ビッグデータ分析基盤マイグレーション #AWSSummit

【レポート】非インフラエンジニアでもできる!ビッグデータ分析基盤マイグレーション #AWSSummit

Clock Icon2019.06.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、大前です。AWS Summit盛り上がってますね。

Day2のセッションである「非インフラエンジニアでもできる!ビッグデータ分析基盤マイグレーション」を受講したので、レポートを記載します。

本ブログは、AWS Summit 2019 day2のセッションレポートになります。

セッションレポート

登壇者

株式会社セガゲームス

研究開発ソリューション統括部

開発技術部 テクニカルリサーチ課

村上 宰和様

概要

スマホゲームビジネスにおいて、ユーザ行動分析とこれを支えるビッグデータ分析基盤はもはや必要不可欠である一方、設備投資と運用工数が莫大になりがちなこのデータ基盤をいかに合理化するかも極めて重要です。本来は高度なインフラ技術専門性を要求されるこの作業に対し、我々「非インフラエンジニア」が自社オンプレミスデータ基盤のAWSマイグレーションを通してどのように挑んだのかを、できる限り生々しく紹介いたします。

Agenda

  1. マイグレーション前夜
  2. マイグレーション作業
  3. 総括
  4. ToBe

1. マイグレーション前夜

データ分析基盤の設置目的

  • ユーザー行動データ分析にもどづく運営が大事である
  • そのためデータ分析を行うための基盤も必要

旧データ分析基盤構成

  • ゲーム環境とは異なる構成
  • Hadoop中心
    • リクエストは多くはないが一個一個のクエリが非常に巨大だった
    • パワフルで巨大なDBが必要だった
  • 2種類のデータ経路
    • ユーザー行動データ
    • ユーザーのゲーム内資産データ
    • 流し込んだ後は集計しBIツールでデータを活用

危機

  • あらゆる障害が同時多発的に出現
    • インフラエンジニアのチーム離脱
    • 上層部からのランニングコスト縮小の圧力
    • オンプレでの設置場所からの退去指示

-> 急遽データ分析基盤マイグレーションを迫られた

  • マイグレーションに課せられた厳しい条件
    • マイグレーション完了デッドラインまで10ヶ月
    • 非インフラエンジニア平均1.25人で完遂しなければよかった

-> こうなったらクラウド使うぞ!

2.マイグレーション作業

0. 段取り

  • 10ヶ月の内訳
    • クラウド選定 5ヶ月
      • そもそもクラウドに詳しくなかったためここに時間を多く準備した
    • 審議 2ヶ月
    • システム構築・データマイグレーション 2ヶ月
      • 構築期間短くない?
      • 設計まで完了しておけばあとはやるだけの想定

1. クラウド選定

  • 最初からパブリッククラウドを使うことは決めていたので、BIG3+1社でどれを使うか検討することに
  • 各社のSAに設計相談
サービス検証
  • 設計に登場したサービスは全て実際に試す
  • 特にデータレイクとクエリエンジンを重点的に検証した
評価と選定
  • 熟慮の上、AWSに決定
  • 決め手は?
    • 非常に使い勝手が良いS3
    • 突出してはいないが手堅くタフなサービス群
    • 整っていて使いやすいマネジメントコンソール
    • 豊富なオンラインドキュメント
    • 比較的ローコスト

2. 稟議

構成決定・コスト算出
  • どのサービスをどれだけ使用するのか、かなり詳細に見積もる必要があった
    • SIMPLE MONTHLY CALCULATORをフル活用
    • 細かく金額を見積もることが出来るためかなり役に立った
しかし
  • AWS経験豊富なIT部門から差し戻される
  • オンプレの撤去期間を先延ばしにしてもらえた 10ヶ月 -> 14ヶ月
追加検証
  • 特に懸念事項とされたRedshiftとAthenaについて追加検証を実施
  • 調べてみたところ見積もりがかなり甘かった事を実感
  • 比較的軽量のクエリはRedshift dc2.large、比較的重量のクエリはAthenaが適していることが判明
  • 見積もり上のRedshiftの台数増加、Athenaの併用検討
稟議再申請
  • 無事通った!

3. システム構築

データレイクS3の構築
  • とても便利なサービスだがディレクトリ構造を決めておかないとカオスになってしまう
  • 事前にどういうディレクトリ、命名規則でデータを格納するのかを固めた
データレイクへデータを流し込む経路
  • ストリーム式にデータを入れたかったのでKinesis Firehoseを使う想定だった
  • 実際やってみるとFirehoseだけでは片付けられなかった
  • ログの振り分けや圧縮作業等をLambdaを挟み込んで実行する構成に
ゲームデータのバッチ処理
  • セキュリティ的な問題でゲームDBをデータ基盤側で都度復元する事に
  • データ基盤側でスナップショットからDBを復元し、DataPipelineを使ってS3にデータを流す
  • 良い悪いはともかく、5TBを上げたり下げたりするのは珍しいらしくAWSから連絡がきた
集計部分
  • EC2はできれば使いたくなかったが止むを得ず使用
  • EC2上にアプリケーションを乗っける
  • 死活監視などで手が掛かるため、別サービスへの置き換えを検討している(Stepfunction)
データマイグレーション
  • データそのもののマイグレーションも侮れないため、Snowballを検討
  • 数百TBのデータマイグレーションは非常に時間がかかる
  • SnowballというAmazonならではの画期的なサービス利用を検討
  • 今回はデータセンタの事情などで利用を見送り
  • 2ヶ月かけてDistcpによる根性でのマイグレーションを行った

4. リリース

  • 直したい箇所もあるが、やりきることが大事ということでリリースすることに
  • リリース直後はほぼノートラブル
  • しばらく日数経過後も、特に目立った障害なく新データ分析基盤が稼働

3. 統括

マイグレーションで実現できた内容

  • コストと運用人員が1/3になった
  • 障害に強くスケールもするシステム
  • 平均復旧時間が1日程度->数分程度になった
  • 非インフラエンジニアでもマイグレーションできる自信がついた
  • 障害が減ったのでより安心して眠れるようになった

教訓

  • AWSを能動的に活用しよう!
    • SAなどのサポートを有効活用しよう
    • 豊富なドキュメントにあたろう
  • すぐに小さく初めて大きく育てよう!
    • サービスの機能とコスト感の体得が最優先
    • 構成はあとで大きくできるから、まずは小さく
    • 予算に注意
  • 常に構成を改善しよう!
    • AWSはユーザへのフィードバックを大切にする会社なので、サービス自体が常に改善されている
    • 合わせてシステム構成改善も検討すべき

4. ToBe

  • 1エンドユーザとして新データ基盤を使う側に
  • 機械学習系サービスを使い倒したいと思っているがたくさんある

セッション感想

実案件を元にしたセッションは現場で培われた知見が詰まっているので、聞いていてとても楽しかったです。

個人的には、「出てきたサービスは全部触ってみる」という部分が非常に大事なポイントだったのではと感じました。

触ると覚えますし、触らないと学べないことが多いですよね。私自身も教訓としていきたいです。

以上、AWS事業本部の大前でした!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.